Bases de datos distribuidas (DDB):
Se definen como colecciones de BDs lógicamente relacionadas y distribuidas a través de una red de computadoras. Son manejadas por un DDBMS que busca hacer transparente la distribución al usuario y que sus nodos cumplan con una serie de características.
Dada una consulta su estrategia de ejecución depende del tipo y la topología de la interconexión entre los nodos de la red (LAN, WAN, conexión directa, conectividad). También depende de la forma en que esté distribuida la información (dada una junta debemos atender a la cantidad de datos que deben ser transeridos).

Transparencia:
Se basa en ocultar los detalles de implementación a los usuarios finales. Si es total, la visión del usuario es la de una DB centralizada donde se centra en la independencia entre datos lógicos y físicos (con el compromiso del sobrecosto de proveerla). De otra manera, el grado de transparencia viene dado por:
- Organización de los datos: Cómo están distribuidos los datos a través de la red. Se divide en transparencia de ubicación (ejecutar una tarea independientemente de dónde estén los datos) y de nombres (tras asociar un nombre a un objeto no hacen falta datos adicionales para ubicarlo).
- Fragmentación: Cómo están fragmentados los datos. La distribución de la relación en subrelaciones puede ser horizontal (sharding: subconjuntos de tuplas) o vertical (subconjuntos de columnas).
- Replicación: Si los objetos están replicados en varios sitios para mejorar la disponbilidad, rendimiento y confiabilidad.
- Otros aspectos: Cómo está diseñada la DDB y cómo se ejecutan las transacciones.

Características esperables:
- Disponibilidad y confiabilidad: Se refieren a la probabilidad de que un sistema se encuentre continuamente disponible u operando en un determinado intervalo de tiempo (respectivamente, aunque los términos se usen de forma indistinta). Ante las fallas del sistema, un sistema confiable puede:
-- Enfatizar su tolerancia a las fallas}, reconociendo que pueden ocurrir y diseñar mecanismos que las detecten y las remuevan antes de que ocurran.
-- Asegurar la ausencia de fallas en el sistema final mediante procesos de desarrollo que incluyen control de calidad y testing.
En el caso de los DDBMSs, estos deben tolerar fallos de sus componentes subyacentes sin alterar los pedidos de sus usuarios ni la consistencia de la base. El RM se encarga de tratar fallas en las transacciones, hardware y comunicaciones en las redes.
- Escalabilidad y tolerancia a la partición: La primera se refiere a la medida en que un sistema puede expandirse mientras continúe operando ininterrumpidamente. Puede ser horizontal (cantidad de nodos del sistema distribuido) o vertical (capacidad de un nodo individual).
La segunda implica que el sistema pueda seguir operando aún cuando la red se particione.
- Autonomía: La medida en que los nodos individuales de una DDB puedan operar independientemente. Se busca que tenga alto grado y hay de varios tipos:
-- Diseño: Uso del modelo de datos / técnicas de gestión de transacciones.
-- Comunicación: Medida en la que los nodos deciden compartir o no información con otros.
-- Ejecución: Acciones "a gusto" del usuario.

Ventajas de las DDBs:
- Permiten mejorar sencilla y flexiblemente el desarrollo de aplicaciones, debido a la transparencia de control y distribución de los datos.
- Aumentan la disponibilidad al aislar las fallas a su sitio de origen.
- Mejoran la performance al mantener cerca los datos necesitados.
- Permiten expandir el sistema a través de la escalabilidad horizontal y vertical.

Fragmentación:
Los fragmentos son las partes resultantes de dividir la DB en unidades lógicas. La fragmentación puede ser:
- Horizontal (sharding): Subdivisión en subconjuntos de tuplas de la relación original. Es análoga al operador SELECT y de comprender a todas las tuplas se denomina completa (puede ser disjunta). La reconstrucción viene dada por UNION.
- Vertical: Subdivisión en subrelaciones dadas por un subconjunto de columnas de la original. Es análoga al proyector y si cada atributo está en al menos una proyección y todas comparten sólo la PK se denomina completa. Su reconstrucción viene dada por OUTER JOIN.
- Mixta: Combinación de las dos anteriores que puede reconstruir la relación con las operaciones en el orden apropiado.
Un esquema de fragmentación de una DB es un conjunto de fragmentos que incluye a todos sus atributos y tuplas, y permite reconstruirla con la secuencia de operaciones apropiada. Por otra parte, un esquema de asignación describe la ubiación de los fragmentos en los nodos de la DDB y de estar uno en más de un lugar se denomina replicado.

Replicación:
Las replicas son copias de los datos que permiten aumentar su disponibilidad y confiabilidad. Según su nivel, la replicación es:
- Total: Todos los nodos tienen copias de la DB.
Ventajas: El sistema puede continuar operando si al menos uno está disponible y mejora el rendimiento de lecturas.
Desventajas: El rendimiento de escrituras empeora y las técnicas de control de concurrencia y recuperación son más costosas.
- Nula: Caso adverso al anterior en que ningún elemento está replicado.
Ventajas: Las escrituras son menos costosas y no requieren de tanto control de concurrencia ni recuperación.
Desventajas: Tiene múltiples puntos de falla y cuello de botella para lecturas.
- Parcial: Algunos elementos se replican y otros no, distribuyéndose a sitios particulares. Esta depende de las metas de disponibilidad, performance y el tipo de transacciones de cada sitio del sistema. La descripción de la replicación viene dada por el esquema de replicación.

Control de concurrencia (CC) en DDBs:
Este subsistema se encarga de mantener la consistencia entre las copias de un data ítem en la DB (mientras intenta mantener el resto de las propiedades de las bases centralizadas). Para ello se puede usar la técnica de locking en donde para cada ítem se designa una copia como distinguida y los pedidos de lock y unlock son enviados a ella.
Según su ubicación, se tienen diferentes variantes:
- Sitio primario: Todas se mantienen en el mismo sitio. De esa forma, al concederse una lectura de un ítem X se puede acceder mediante cualquier copia y si es una actualización, el DDBMS se debe encargar de que se propague al resto de las copias.
Ventajas: Es una extensión del esquema centralizado y si las transacciones cumplen con el enfoque 2PC la seriabilidad está garantizada.
Desventajas: Hay cuello de botella en el único sitio así como un único punto de falla que puede paralizar al sistema.
- Sitio primario + backup: Similar al anterior pero con un sitio adicional de backup para reemplazar al primario en caso de fallar.
Ventajas: Simplifica el proceso de recovery del sitio primario.
Desventajas: La performance de locking disminuye y persiste el problema del cuello de botella.
- Copia primaria: Permite que las copias distinguidas se almacenen en diferentes lugares.
Ventajas: Ataca el problema del cuello de botella y el único punto de falla del sitio primario. De combinarse con backups, se puede mejorar su disponibilidad y confiabilidad (aunque con cierto costo adicional).
Desventajas: Una transacción puede necesitar locks en varios lugares.

Elección de nuevo coordinador: Al suceder una falla, en los casos sin backup las transacciones que acceden a los datos del sitio afectado deben ser abortadas y reiniciadas, mientras que de haber backup estas son suspendidas hasta ser designados estos sitios como primarios. Si ambos fallan puede iniciarse un proceso de elección de un nuevo coordinador desde un sitio Y:
- El coordinador se considera fallido si el sitio Y intenta reiteradamente comunicarse con él y no lo logra.
- Luego, este sitio envía a todos los nodos activos que será el nuevo coordinador.
- De recibir la mayoría de los votos positivos, se lo declara como tal. Esto resuelve los casos en que más de un sitio desea ser coordinador a la vez.

Votación: Alternativamente a la copia distinguida, se puede hacer un pedido de lock(X) a todos los sitios con el ítem X. De allí, cada copia puede aceptarlo o rechazarlo. Si recibe la mayoría de aprobaciones en un cierto período de tiempo, les avisa a todas las copias que tomó el ítem. Si no, cancela el pedido y les informa de la cancelación.
Ventajas: Es un método de CC realmente distribuido por compartir la decisión entre sus nodos.
Desventajas: Genera mucho tráfico de mensajes y de caerse nodos durante la votación el algoritmo puede acomplejizarse.

Recuperación en DDBs:
Este subsistema debe atender a dos principales problemas:
- Fallos en sitios y comunicaciones: A partir de un sitio X es difícil determinar si un sitio Y se encuentra caido sin intercambiar una gran cantidad de mensajes. En efecto, la falta de respuesta de Y podría deberse además a una falla en la comunicación que hace que no haya recibido el mensaje o no haya podido enviarlo.
- Commit distribuido: Cuando una transacción actualiza un valor en varios sitios, no puede commitearlo hasta asegurarse que sus efectos no se perderán en ninguno de ellos (log). Para asegurar la correctitud frente a este problema se suele usar el protocolo 2PC.

Gestión de transacciones distribuidas:
En las DDBs tenemos varios módulos encargados de garantizar las propiedades ACID: gestor global de transacciones, local de transacciones, de CC y de recovery. El primero actúa en el sitio de origen de la transacción y le pasa la operación al de CC. Este se encarga de manejar los locks y hasta adquirirlo bloquea a la transacción. Tras obtenerlo, el runtime processor ejecuta la operación y luego libera el lock y le avisa al gestor de transacciones del resultado.

Protocolo 2PC: En este actúan los gestores de recovery (global y local con su información correspondiente) y el TM del nodo coordinador de la operación a realizar. Se divide en dos fases:
- Primera fase: El coordinador le avisa a todos los nodos que estén listos para realizar el commit (o abort) y espera recibir la mayoría de aprobaciones para pasar a la siguiente fase (dentro de un tiempo de timeout). Si no lo hace, aborta la operación.
- Segunda fase: El coordinador les dice a todos los nodos que va a ejecutarse el commit (o abort) y espera su respuesta positiva dentro de un tiempo de timeout (si no cancela la operación). Sin embargo, si el coordinador falla tras solicitar el lock, el resto de los nodos pueden quedarse permanentemente bloqueados.
La respuesta a esto es el protocolo 3PC en el que se agrega una fase intermedia de reconocimiento con tiempo de timeout que causa abort entre la primera y la segunda, y commit entre la segunda y la tercera para estos sitios y evita que se bloqueen.

Gestión de consultas distribuidas:
El procesamiento de las consultas se divide en etapas:
1) Mapeo: Se pasa la consulta SQL a AR basándose en el esquema conceptual global y se normaliza y reestructura de manera similar al caso centralizado.
2) Localización: Se mapea la consulta resultante a múltiples fragmentos individuales en base a la información de distribución y replicación de datos.
3) Optimización de la consulta global: Se selecciona una estrategia de una lista de candidatas cercanas a la óptima en base a algún criterio: tiempo, costo total, comunicación, entre otros.
4) Optimización de la consulta local: Se ejecuta en todos los nodos de la DDB con técnicas de optimización centralizadas.

Semijoin: En la tercera etapa, un gran costo a considerar es el de la cantidad de datos a transferir. Una manera de mitigarlo es intentar reducir la cantidad de tuplas de una relación antes de la transferencia. Así, el semijoin consiste en enviar sólo la columna de la junta, realizarla y de su resultado retornarla junto con los atributos necesarios para completar la consulta.
Ventaja: Si sólo una pequeña parte de la relación participa en la junta se puede minimizar la transferencia de datos.
Desventaja: Es una heurística y puede fallar.

Tipos de DDBs:
Los sistemas de DDBs pueden diferir según el grado de:
- Homogeneidad: Si todos los servidores y usuarios hacen uso del mismo software. Aquí la heterogeneidad puede surgir por diferencias en:
-- Modelo de datos: Pueden diferir en su modelo relacional, objetos o archivos (por ejemplo, la misma información puede ser tratada como un atributo o una relación). Sobre esto es necesario un mecanismo inteligente de procesamiento de consultas que relacione la información basándose en metadata.
-- Restricciones: Varían de sistema a sistema y deben ser tratadas por el esquema global.
-- Lenguaje de consultas: Dentro del mismo modelo de datos puede tener diferentes versiones.
También puede haber heterogeneidad semántica si hay diferencias en el significado, interpretación y uso de los datos, gracias a la autonomía de diseño. Se puede tratar con software variado que administre las consultas y transacciones desde la aplicación global a cada DB y visceversa: middleware, application servers, enterprise resourse planning, modelos y herramientas para la integración e intercambio de datos y acceso/consulta a datos basado en ontologías.
- Autonomía local: Cuánto depende cada sitio del resto para funcionar como un DBMS por separado. Tenemos de varios tipos:
-- Comunicación: Capacidad de decidir cuándo comunicarse con el resto.
-- Ejecución: Capacidad de un componente de la DB de ejecutar operaciones sin interferir con las del resto y decidir su orden.
-- Asociación: Capacidad de decidir si compartir y cuánto su funcionalidad y recursos.
De aquí se derivan FDBS y p2pDBS, en los que cada servidor sea independiente y autónomo con usuarios locales propios, transacciones locales y un DBA (alto grado de autonomía). En el primero hay cierto esquema global de la federación de bases de datos, mientras que en el segundo cada nodo se construye a medida que se lo necesita. Como sus nodos son heterogéneos, es necesario un lenguaje canónico para traducir las consultas.

Arquitecturas paralelas y distribuidas:
Dentro de las arquitecturas de sistemas multiprocesador tenemos las de:
- Memoria compartida: Múltiples procesadores que comparten memoria primaria y tienen almacenamiento secundario (disco).
- Disco compartido: Múltiples procesadores que comparten almacenamiento secundario pero comparten su memoria primaria.
- Shared-nothing: Cada procesador tiene su propia memoria y disco. Se comunican a través de redes de alta velocidad. Se busca cierta simetría y homogeneidad entre los nodos.
De estas se derivan tipos particulares de arquitecturas:
- Parallel DBMS (PDBMS): Son un caso particular de las distribuidas usadas en la industria donde los nodos se encuentran físicamente cerca y se conectan entre sí a través de una red local de alta velocidad. Esto hace que su costo de comunicación sea bajo y puedan implementarse con los 3 tipos mencionados de arquitectura multiprocesador. Su principal diferencia con las distribuidas reside en su modo de operación.
- Distribuidas puras: Cada nodo está en un sitio diferente y se comunican a través de una red con un costo no despreciable. Se basan en la arquitectura shared-nothing y tienen un esquema conceptual global y uno interno a cada nodo que junto con el catálogo permiten imponer restricciones y optimizar las consultas locales y globales.
- 3-Tier: Se desarrollan en el contexto de arquitecturas cliente-servidor y se separan en 3 capas:
-- Presentation: La interfaz que interactúa con el usuario.
-- Application: La encargada de manejar la lógica de negocios de la aplicación.
-- Database Server: La encargada de manejar, procesar y retornar los pedidos de consulta y actualizaciones de la capa de aplicación.
Aún así, las funcionalidades DDBMS puede dividirse de diferentes maneras. Más en detalle, la capa de aplicación debe primordialmente encargarse de:
-- Generar un plan de ejecución distribuido para las consultas y transacciones y supervisar su ejecución.
-- Asegurar la consistencia entre réplicas con técnicas de control de concurrencia distribuida.
-- Asegurar la atomicidad de las transacciones globales, ejecutando un recovery global en caso de producirse una falla.
Esta capa no siempre puede operar con transparencia de distribución, es decir, sin especificar los sitios en que residen los datos de las consultas o transacciones.

Catálogo:
Es una DB que contiene la metadata del DDBMS, particularmente la información de la fragmentación, asignación de fragmentos y replicación de los datos. Su administración debe tener autonomía de sitio, vistas y distribución y replicación de los datos. Su esquema puede ser:
- Centralizado: Se almacena por completo en un sitio
Ventajas: SU implementación es sencilla.
Desventajas:
-- Tiene poca confiabilidad, disponbilidad y autonomía.
-- Centraliza la distribución de la carga de procesamiento.
-- Los locks pueden producir un cuello de botella en caso de haber muchas escrituras.
- Totalmente replicado: Cada sitio tiene una copia completa del catálogo.
Ventajas: Puede responder a las consultas localmente.
Desventajas: Las actualizaciones deben ser transmitidas a todos los sitios, por lo que se requiere de un esquema centralizado 2PC para mantener la consistencia y las aplicaciones de muchas escrituras, incrementando así el tráfico de la red.
- Parcialmente replicado: Cada sitio tiene la información completa del catálogo de los datos almacenados localmente en el sitio. Además pueden almacenar en caché copias de entradas de otros sitios (no necesariamente actualizadas). Luego, el sistema debe registrar para cada entrada del catálogo los sitios en que se creó el objeto y en donde están sus copias para propagar los cambios de ellas al original.

Teorema CAP:
Publicado en 1998 y presentrado por Eric Brewen en el año 2000, establece que cualquier sistema que comparta datos a través de la red puede cumplir con a lo sumo dos de las siguientes propiedades:
- Consistency: Asegurarse de que haya un único valor para todos datos.
- Availability: Alta disponibilidad para actualizar y acceder a los datos.
- Partition tolerance: Tolerancia a posibles particiones de la red.
Según Brewen, el objetivo del teorema debe enfocarse en encontrar el balance entre consistencia y disponbilidad mientras se encuentra la forma de manejar las particiones de la red, considerando cómo recuperarse ante eventuales fallas. Para lo segundo, el sistema debe detectar la partición, entrar en modo "particionado" y luego recuperar el modo anterior.